As has more applications, services and content sources (collectively “resources”) have become available on servers accessible over networks, it has become more common for remote users and/or programs (collectively “consumers”) to access those resources on such servers over such networks. But communicating with a resource on a server, via a network requires formatting communications consistently with a protocol supported by the network and/or server, which complicates such communications. There are many protocols supported by many different networks and/or servers. For example, messages traversing the Internet can be formatted in protocols including, but not limited to, Hypertext Transfer Protocol (HTTP), File Transfer Protocol (FTP) and Simple Mail Transport Protocol (SMTP). Such a diversity of protocols facilitates communications between a wide range of consumers and resources in a variety of methods. But such diversity also leads to problems for programmers trying to access resources available on servers reachable through different networks and by different protocols.
Conventionally, a program written to access a resource provided over a network had to include code specific to the protocol employed to transport messages across the network. For example, a programmer writing a peer-to-peer application for sharing files across a network had to include code specific to the protocol between the peer processes. Including such protocol specific code in a program can negatively impact writing such a program by requiring the programmer(s) involved in writing the program to learn and account for protocol details. Learning such protocol specific details, and coding to account for such protocol specific details can increase program complexity while reducing program flexibility, thus increasing programming costs. Since protocols can change, program flexibility is important to program utility and lifespan, and thus to reducing lifetime costs associated with a program. For example, a program written to communicate specifically via HTTP 1.0 may not be able to communicate via HTTP 1.1. Thus, the program may need to be rewritten and recompiled to take advantage of the newer protocol, adding complexity and related cost to the program.
Programmers writing programs that seek to interact with resources addressable by a URI (Uniform Resource Identifier) typically are required to know the URI, to know the protocol employed to access the URI and to write code specific to the protocol required to access that URI. Thus, changing the URI of a resource could require a program to be rewritten and recompiled, thus introducing opportunities to introduce new bugs into a system. Thus, conventional systems limit the relocatability of resources.
Programmers are further constrained by conventional systems and methods that require a program to transmit and receive messages in message sizes and formats dictated by a protocol. For example, a protocol supporting transferring email messages may require an email message comprising a thousand words to be transmitted as a series of packets with headers and/or trailers according to that protocol. Similarly, a book chapter comprising twenty kilobytes of data may be received as a series of one kilobyte blocks according to a second protocol. Such protocol specific size restrictions add complexity to programs and limit the ability of one program to access multiple different resources available over a variety of protocols.
Thus a system and/or method for simplifying application communications over a plurality of protocols is still needed to mitigate problems associated with conventional systems.